Skip to content

Implemented ordering for expanded iterators #8741

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
JPPhoto wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Implemented ordering for expanded iterators #8741

JPPhoto wants to merge 14 commits into from
+114 −13

Conversation

@JPPhoto
Copy link
Collaborator

@JPPhoto JPPhoto commented Jan 6, 2026 •
edited
Loading

Summary

Feature: best-effort in-order execution for nodes expanded by IterateInvocation, subject to ready state.

Why: iteration-expanded work could run in an arbitrary order when multiple iteration branches become ready at the same time, which reduces determinism and makes behavior harder to reason about.

How: compute a cached per-exec-node "iteration path" (outer to inner indices for nested iterators, respecting collector boundaries) and use it to ordered-insert ready nodes into the existing per-class ready queues. FIFO is preserved for equal iteration paths, and no blocking is introduced.

Related Issues / Discussions

QA Instructions

Create a collection, note the ordering, then iterate and pass values to a series of other nodes. Check that the outputs use the source collection's items in order.

Merge Plan

Checklist

  • The PR has a short but descriptive title, suitable for a changelog
  • Tests added / updated (if applicable)
  • ❗Changes to a redux slice have a corresponding migration
  • Documentation added / updated (if applicable)
  • Updated What's New copy (if doing a release after this PR)

@github-actions github-actions bot added python PRs that change python files services PRs that change app services labels Jan 6, 2026
@JPPhoto JPPhoto added backend PRs that change backend files enhancement New feature or request and removed python PRs that change python files services PRs that change app services labels Jan 6, 2026
@JPPhoto
Update test_graph_execution_state.py
fb8de3f 
Added a test for nested iterator execution ordering. (Failing at commit time!)
@github-actions github-actions bot added python PRs that change python files services PRs that change app services python-tests PRs that change python tests labels Jan 6, 2026
JPPhoto added 3 commits January 5, 2026 19:21
@JPPhoto
Filter invalid nested-iterator parent mappings in _prepare()
526d082 
When a graph has nested iterators, some "ready to run" node combinations do not actually belong together. Previously, the scheduler would still try to build nodes for those mismatched combinations, which could cause the same work to run more than once. This change skips any combination that is missing a valid iterator parent, so nested iterator expansions run once per intended item.
@JPPhoto
Merge branch 'main' into iterator-expansion-ordering
9c5ee7a
@JPPhoto
Merge branch 'invoke-ai:main' into iterator-expansion-ordering
5bcbafb
@JPPhoto JPPhoto marked this pull request as ready for review January 6, 2026 17:04
lstein
lstein reviewed Jan 11, 2026
View reviewed changes
Copy link
Collaborator

@lstein lstein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to be able to review this PR, but I've never quite understood how to use the collection/iteration functions in the workflow editor and don't think I have the expertise to identify edge cases and so forth.

If no one else is able to review, I'll come up to speed and give it a shot.

@lstein
Copy link
Collaborator

lstein commented Jan 15, 2026

Following up on this, maybe you can provide an example workflow that illustrates the problems with the previous non-deterministic execution ordering and demonstrates how the PR fixes this?

@JPPhoto
Copy link
Collaborator Author

JPPhoto commented Jan 15, 2026

Following up on this, maybe you can provide an example workflow that illustrates the problems with the previous non-deterministic execution ordering and demonstrates how the PR fixes this?

As it's non-deterministic, I can't guarantee that any example will show anything at all. The problem is that when iteration expands, prior to this change the resulting nodes are treated like any others and there are no guarantees that the collection of expanded nodes will execute in any order at all. After this change, the first iteration's nodes should always complete before the second iteration's start, the second's before the third's, etc.

Hopefully this change accomplishes that; this section of code is getting very hard to read and understand and would likely benefit from a major refactor at some point.

@JPPhoto JPPhoto requested a review from lstein January 15, 2026 19:24
@JPPhoto JPPhoto marked this pull request as draft January 15, 2026 23:10
@JPPhoto
Copy link
Collaborator Author

JPPhoto commented Jan 15, 2026

Drafting this as the collect node needs some adjustment even though execution seems to happen in order.

@JPPhoto
Copy link
Collaborator Author

JPPhoto commented Jan 15, 2026

Sample workflow: OrderingTestWorkflow.json

Before this PR, examining the output of the Integer Addition node:

[
    {"output_meta": null, "value": 1002, "type": "integer_output"},
    {"output_meta": null, "value": 1003, "type": "integer_output"},
    {"output_meta": null, "value": 1008, "type": "integer_output"},
    {"output_meta": null, "value": 1001, "type": "integer_output"},
    {"output_meta": null, "value": 1000, "type": "integer_output"},
    {"output_meta": null, "value": 1007, "type": "integer_output"},
    {"output_meta": null, "value": 1004, "type": "integer_output"},
    {"output_meta": null, "value": 1009, "type": "integer_output"},
    {"output_meta": null, "value": 1006, "type": "integer_output"},
    {"output_meta": null, "value": 1005, "type": "integer_output"}
]

After:

[
    {"output_meta": null, "value": 1000, "type": "integer_output"},
    {"output_meta": null, "value": 1001, "type": "integer_output"},
    {"output_meta": null, "value": 1002, "type": "integer_output"},
    {"output_meta": null, "value": 1003, "type": "integer_output"},
    {"output_meta": null, "value": 1004, "type": "integer_output"},
    {"output_meta": null, "value": 1005, "type": "integer_output"},
    {"output_meta": null, "value": 1006, "type": "integer_output"},
    {"output_meta": null, "value": 1007, "type": "integer_output"},
    {"output_meta": null, "value": 1008, "type": "integer_output"},
    {"output_meta": null, "value": 1009, "type": "integer_output"}
]

But, as I indicated above, there's something up with the Collect node.

@JPPhoto JPPhoto marked this pull request as ready for review January 16, 2026 03:06
@JPPhoto
Copy link
Collaborator Author

JPPhoto commented Jan 16, 2026

Collect ordering is now resolved. Try the test workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@blessedcoolant blessedcoolant Awaiting requested review from blessedcoolant blessedcoolant is a code owner

@dunkeroni dunkeroni Awaiting requested review from dunkeroni dunkeroni is a code owner

@Pfannkuchensack Pfannkuchensack Awaiting requested review from Pfannkuchensack

@lstein lstein Awaiting requested review from lstein lstein is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

backend PRs that change backend files enhancement New feature or request python PRs that change python files python-tests PRs that change python tests services PRs that change app services

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@JPPhoto @lstein